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FIELD 

[0001] This invention relates to matching and interaction of clients and 
Internet services, more particularly, dynamically interacting, at runtime, with an 
Internet service using a client specified communication proxy type and protocol, 
the client and the Internet service matched by a broker. 

BACKGROUND 

[0001] Several technologies are available for discovering devices and 
web services, including Salutation, E-Speak, Jini, and Universal Description 
Discovery and Integration (UDDI). These technologies are often employed by 
Internet services, clients that request Internet services, and brokers to help 
coordinate interaction between an Internet service and a client. Salutation and 
E-Speak rely on a proprietary transport that funnels through a broker, requiring 
clients and services to be built with respective products such that both use an 
agreed protocol. Jini provides a Java object to clients to interact with a service, 
requiring the Java object to interact with another Java object alone, whether it 
is a Java client or a Java wrapper. The protocol used between the Java object 
and the service is determined by the service. UDDI provides a client with Web 
Service Description Language (WSDL) and the client develops a 
communications code based on methods and parameters disclosed by the 
WSDL. 

[0002] Currently employed technologies utilize a service, a broker and a 

communications proxy for clients to interact with an Internet service, but they 
fail to provide a method, a required Application Program Interface (API) and 
implementations for clients to specify a desired application-level transport 
protocol and a language/component technology. With current technologies, a 
client has no ability to specify a protocol that makes the most sense for the 
client. As an example of a conventional method, Jini, a server centric model, 
provides a Java object to clients to interact with a service. There is no 
negotiation between the service and the client for type of proxy. The protocol 
used between the Java object and the service is determined by the service. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[0003] Additional advantages of the invention will become apparent upon 
reading the following detailed description and upon reference to the drawings, 
in which: 

Fig. 1 depicts a representation of the interaction of four invention components 
overtime in an embodiment of the invention; 

Fig. 2 is a flow diagram depicting the operation of an embodiment of the 
invention; 

Fig. 3 is a flow diagram depicting Client functions, in an embodiment of the 
invention; 

Fig. 4 is a flow diagram depicting Broker functions, in an embodiment of the 
invention; and 

Fig. 5 is a flow diagram depicting Service functions, in an embodiment of the 
invention. 

DETAILED DESCRIPTION 

[0004] Exemplary embodiments are described with reference to specific 
configurations. Those of ordinary skill in the art will appreciate that various 
changes and modifications can be made while remaining within the scope of 
the appended claims. Additionally, well-known elements, devices, 
components, circuits, process steps and the like are not set forth in detail in 
order to avoid obscuring the present invention. 

[0005] As existing businesses and new businesses expand to the 
Internet, brokers and repositories play an increasing role as focal points in the 
Internet infrastructure. In an embodiment of the invention, a method is 
provided for clients to locate Internet services fulfilling the clients needs. In 
contrast to currently employed technologies, an embodiment of the invention 
provides a client centric model. Clients and Internet services are matched by a 
broker. In an embodiment of the invention, clients specify a type of 



2 



communications proxy that can be different than a proxy used by an Internet 
service, promoting interaction between heterogeneous systems. In an 
embodiment, the invention provides a method and apparatus for clients to 
dynamically interact, at runtime, with an Internet service using at least one of a 
client specified language/component technology and a client specified 
application-level communications protocol. In an embodiment, a client 
requests, to a broker, a specific language/component technology 
(communication proxy), and, optionally, an application-level transport protocol. 
The broker matches the client request and an Internet service, and transmits 
metadata to the client enabling the client to locate the matched Internet service 
communication proxy. The language/component technologies include Java, 
common language runtime (CLR), component object model (COM), Win32 
binaries, etc. The application-level communications protocols include hypertext 
transfer protocol (HTTP), simple mail transfer protocol (SMTP), simple object 
access protocol (SOAP), secure sockets layer (SSL/HTTPS), secure HTTP (S- 
HTTP), etc. In an embodiment, the client downloads the requested 
communication proxy and dynamically interacts, at runtime, with an Internet 
service using the requested communication proxy, the communication proxy 
being local to the client. In an embodiment of the invention, a client application 
is executing, and during runtime the client is interacting with the 
communications proxy. By "dynamically interact" it is meant, in an embodiment 
of the invention, that the client has no prior knowledge of what is needed to 
interact with an Internet service. In an embodiment of the invention, the client 
is relieved from having to develop a remote communications code. 

[0006] As shown in Fig. 1, four components, namely, Client 100, Broker 
102, Service 104, and Proxy 106 are involved in interaction in an embodiment 
of the invention. While the components interaction is presented with respect to 
advancing time, the interaction is variable, and not restricted to the interaction 
depicted. Fig. 1 presents an enhanced visual representation of the functional 
blocks of Fig. 2. 

[0007] As shown in Fig. 2, in an embodiment of the invention, a method 
is provided utilizing the four components represented in Fig. 1. As shown in 
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functional block 200, Service 104 registers with Broker 102, transmits metadata 
describing any communication proxies, and provides attributes or keywords 
that describe the service as well as information pertaining to any 
communications proxies. In an embodiment of the invention, the metadata 
data can be XML, hyper text markup language (html), text file, binary, etc. 
Service 104 can provide any proxy it desires, including CLR, Java, COM based 
communications proxies, Win32 binaries, etc. The communications proxy 
information includes the number of proxies, proxy location, proxy type and 
supported protocols. The supported protocols include SOAP, SMTP, 
MQSeries, HTTP, HTTPS, etc. The metadata describes information that Client 
100 requires to interact with Service 104. The information is stored by Broker 
102 for future dissemination to clients finding a matching service. 

[0008] As shown in functional block 202, Client 100 registers with Broker 
102 to request and locate a desired service that provides a client-requested 
type of communication proxy and protocol. As shown in functional block 204, 
Broker 102 locates a match between Client 100 request and Service 104 
registered services. As shown in functional block 206, Broker 102 provides the 
stored metadata to Client 100. In an embodiment, Broker 102 provides a digital 
certificate to Client 100 ensuring the security of downloading the metadata. As 
shown in functional block 208, Client 100 parses the metadata and determines 
the location and name of the communication proxy 

[0009] As shown in functional block 210, Client 100 downloads, to its 

node, communications proxy 106 based on the location provided with the 
metadata returned from the Broker 102. In an embodiment, Client 100 uses a 
protocol to download communications proxy 106. The chosen type of 
communications proxy must be compatible with the environment of Client 100 
so that Client 100 can interact with proxy 106. In an embodiment, after Client 
100 downloads a communications proxy, Client 100 uses dynamic method 
discovery and invocation mechanisms. For example, in an embodiment, 
reflection is used with C sharp (an object-oriented programming language), and 
Client 100 discovers at runtime (as opposed to build-time) the methods and 
parameters within communication proxy 106. In an embodiment, Service 104 
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provides proxies supporting more than one protocol. In an embodiment, Client 
100 downloads one communication proxy from Service 104 and can use 
multiple protocols supported by a single communication proxy. 

[0010] As shown in functional block 212, Client 100 interacts directly with 
local communication proxy 106 to communicate with Service 104. By "local" it 
is meant that Client 100 and proxy 106 share the same node. The interaction 
between Client 100 and Service 104 is simplified since Client 100 interacts only 
with a local component, the communications proxy. 

[0011] Client 100 downloads a communication proxy and interacts with 

Service 104 (by interacting with proxy 106) at runtime. If the type of protocol is 
not significant to Client 100, or if Client 100 fails to choose a protocol, then a 
default protocol of the specified communications proxy is used. In an 
embodiment, Client 100 is required to specify a proxy type. In an embodiment, 
Client 100 is required to specify a proxy type and a protocol. 

[0012] As shown in functional block 214, communications proxy 106 

directly interacts with Service 104 on behalf of Client 100. The remote 
communications burden is left to communications proxy 106. Since Service 
104 provides communications proxy 106, communication proxy 106 includes 
the necessary logic to connect and communicate with Service 104. Client 100 
is relieved of concerns including firewalls of Service 104, since proxy 106 
includes the necessary information and handles such concerns. In an 
embodiment, proxy 106 has accessibility to the intranet and extranet of Service 
104 for any needs of Client 100. 

[0013] In an embodiment, Service 104 provides as many communication 

proxies as it desires. In an embodiment Service 104 provides no 
communications proxies. If no communications proxies are provided by 
Service 104, or if none of the provided communication proxies fulfill the needs 
of Client 100, then, in an embodiment, Client 100 uses a service description 
language provided as part of the metadata and optionally uses SOAP to 
interact with Service 104. In an embodiment, Client 100 receives service 
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description language information from Broker 102 and develops an application, 
its own communications code, to communicate with Service 104. 

[0014] The methods of a client, the methods of a broker and the 
methods of a service individually represent an embodiment of the invention as 
described below. 

[0015] Fig. 3 represents an embodiment of the invention. As shown in 

functional block 300, Client 100 makes a request to Broker 102 to locate a 
desired Internet service with a specific proxy and, optionally, a specific protocol. 
As shown in functional block 302, Client 100 receives metadata from Broker 
302. In an embodiment of the invention, the metadata data can be XML, html, 
text file, binary, etc. As shown in functional block 304, Client 100 parses 
metadata and determines the location and the name of communication proxy 
106. As shown in functional block 306, Client 100 downloads communication 
proxy 106 to Clients node. As shown in functional block 308, Client 100 
dynamically interacts, at runtime, with local communication proxy 106 and 
thereby interacts with Service 104. 

[0016] Fig. 4 represents an embodiment of the invention. As shown in 

functional block 400, Broker 102 receives a registration from Service 104 
including metadata describing communication proxies supporting various 
protocols, and identifying the location of each proxy. In an embodiment of the 
invention, the metadata data can be XML, html, text file, binary, etc. As shown 
in functional block 402, Broker 102 receives a request from Client 100 to locate 
a desired Internet service with a specific proxy and a specific protocol. As 
shown in functional block 404, Broker 102 locates a match between Client 100 
request and Service 104 registration. As shown in functional block 406, Broker 
102 sends metadata to Client 100. 

[0017] Fig. 5 represents an embodiment of the invention. As shown in 

functional block 500, Service 104 registers with Broker 102 transmitting 
metadata describing Service 104, any communication proxies supporting 
various protocols, and identifying the location of each proxy. In an embodiment 
of the invention, the metadata can be XML, html, text file, binary, etc. As 
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shown in functional block 502, Service 104 interacts with Client 100 by 
interacting (exchanging information) with proxy 106, proxy 106 and Client 100 
being on the same node. 

[0018] In an embodiment of the invention, a machine readable medium 
is provided having instructions which when executed by a machine cause the 
machine to perform operations. The operations performed include requesting a 
desired Internet service to a broker, requesting a desired communication proxy 
to a broker, receiving metadata from the broker, receiving the desired 
communication proxy, and interacting with an Internet service using the desired 
communication proxy. In an embodiment of the invention, the machine 
downloads the desired communication proxy to a node local to a client. In an 
embodiment of the invention, the interacting is accomplished at runtime. In an 
embodiment of the invention, the interacting is dynamic interacting. The 
machine-readable storage medium includes any mechanism that provides (i.e., 
stores and/or transmits) information in a form readable by a machine (e.g., a 
computer). For example, a machine-readable medium includes read only 
memory (ROM); random access memory (RAM); magnetic disk storage media; 
optical storage media; flash memory devices; electrical, optical, acoustical or 
other form of propagated signals (e.g., carrier waves, infrared signals, digital 
signals, etc.); etc. 

[0019] Having disclosed exemplary embodiments, modifications and 

variations may be made to the disclosed embodiments while remaining within 
the spirit and scope of the invention as defined by the appended claims. 



7 



